Part 58: Assignment #28: Spoiler-Blocking Headphones
Spoiler-Blocking Headphones
I've seen billboards for Get the Throne around town. If I had to describe it, it'd be Romance of the Three Kingdoms meets what Hollywood did to Arthurian legend over generations. A lot of the other people at the office are fans of it. Me? Well, I'm more one for Lamia's wacky hijinks.
Now, let's see what David's come up with.
This is an interesting idea. The design would have to store a predefined list of keywords from David's big list (which I haven't actually located yet). Then— well, the surprising part is that the headphones have to be passing audio through most of the time! (Naively, I thought the headphones would just play static or do something noise-canceling when they spotted a keyword, but not that they'd relay audio entirely the rest of the time and stay silent. I guess this way was easier to design... presumably, you can just have the headphones block out all outside sounds with insulation, and then the relay design makes sense.)
A look at the datasheet of the natural language chip stirs things up a bit more.
Once again, David's designing for the international market. This is an English-language NLP chip - so the people who'll purchase this are TV-watchers who, not only speak English, but have English spoken around them by other people.
He did pick internationally popular Chinese shows - but this could also easily be adapted for NA shows simply by swapping out the keywords of Get the Throne, with ones from, say, Ms. Broom's Time Police, or maybe Back Stab. The keywords will almost certainly be stored on a memory chip of some kind, so all that needs to happen is that the memory chip goes into a swappable card - put a slot in the headphones to fit? - and then we can sell new cards as new shows come out (and the headphones'll remain useful to boot).
So: let's see this list of his.
There's Get the Throne, second from the top. Truth Investigators made the cut, which isn't surprising at all. Lili's a big fan of that one - very tense (apparently). I hadn't heard of Memories of Tomorrow, but some Googling suggests it's very popular. ("Good at bringing all the feels", end quote.) I am a little worried if we do a card for it, though - some of its keywords seem a bit generic. And at the bottom, we have none other than Lamia! It's got...
Wait... dental insurance?
Dental insurance! THAT was what was in the anniversary gift that was teased in the time skip? Wait, there's only one potential supernatural girlfriend on the show who has biiig snake fangs and would really need dental insurance as a gift. Which means—
—which means I've been spoiled for the season finale, dammit. And after asking everyone on here and everything! And wearing a pair of these fine headphones I'm about to design wouldn't have saved me...
This is going to be one of those days, isn't it.
Anyway, here's how this needs to work.
1. Have two 'modes', as mentioned above - pass-through mode and silent mode. I'm thinking it's probably best if one MC is responsible for passing audio through (or not) while another MC handles keywords.
2. In pass-through mode, the keyword MC checks keywords against the memory chip that has the values in David's list. (The prototype in my simulator doesn't show the card slot, but I'll mention it to David when I email him the final design.) If something trips it, switch the audio MC to silent mode. Otherwise, the audio MC sends audio to the speaker.
3. In silent mode, the audio MC stays silent until the Override button is pressed. Then it goes back to pass-through mode. The keyword MC doesn't have to do anything at this point.
I'll craft the design to this spec and see how it performs.
[ ~ ]
This design came slowly. I'm not really feeling as motivated ever since I saw the bottom of that list... anyway, here it is.
The small MC is the audio MC, which passes keywords through to the big MC (the keyword-checking MC). If the keyword-checking MC doesn't find anything, it'll report "all clear" to the audio MC, which happily passes sound through to the speakers. If a keyword is found, though - that's where it gets interesting.
Basically, the audio MC's "slx x1" means it can wait indefinitely for the "all clear". If the big MC sees a keyword, it just stops (once it's tested against the whole memory chip) and waits for the override button to be pressed - whereupon, it sends 'all clear' to the audio MC, and everything returns to normal.
The memory chip just contains David's Get the Throne keyword data in no particular order (the first and second halves of each keyword are grouped together).
As is, it's ¥10 and 1188 average power, but I'll keep fiddling with this design to see if I can improve it - in particular, there is one bug I can potentially see, where the NLP chip stores (potentially spoiler-related) keywords in its buffer while the audio MC is shut down. When the audio MC resumes after an override, those spoiler keywords (which took place during the part of the conversation the user wasn't listening to) get passed to the keyword MC, shutting everything down again.
This won't be a problem if the user holds override down for a few seconds - the NLP chip's buffer can't be that big - but it's an edge case that's worth looking into.
[ ~ ~ ]
I fixed the bug, but I kind of made it less efficient. It's ¥8 and 1422 average power per run now - and the reason for this is that it keeps testing for keywords once per time unit, even if the audio pass-through is shut off. I had to change the unused slots in the memory chip from -999 to -1 so that the design doesn't think a lack of keyword data ([-999,-999]) is a spoiler and silence it. In the same vein, the input expander is there for the sole reason of not needing to use another simple input pin for the button.
This change does sort the bug out simply because keywords are always tested, and I did save a MC that way. But, at the same time - the old version would skip the test phase if it saw a -999. This version doesn't do that (no space for more code), so it'll test a lot of "keywords" that are really just [-999,-999] when the NLP chip isn't detecting. So because of both the additional keyword tests and the testing of blank input, this design ends up drawing more power.
Which version is best? For once, I can't say that I've made a specific improvement in the design, just a change. This version draws more power, but is more responsive to the override button. But, depending on how it sorts out with hardware and what sort of battery can go into it, the other design could be better! If the power draw in this version is too big, a too-short battery life could dissuade people from using (or buying) the 'phones.
This is the sort of thing that needs real-life testing. I'll send both designs to David and he can figure out things with the factory from there.
Sorry, David, but no one is getting out of this alive.
Now, I'm gonna go home, get some popcorn, top it with some of the cheese Carl gave me, and watch the season finale of My Roommate Is a Lamia!... and I'm gonna like it.
